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I. INTRODUCTION 



This is an appeal from the final rejection set forth in an Official Action dated June 
9, 2006, finally rejecting claims 1 , 2 and 4-38, all of the claims pending in this application, 
as being unpatentable over Beuk et al. (U.S. 5,774,673) ("Beuk"). A Request for 
Reconsideration was timely filed on July 28, 2006. An Advisory Action was issued on 
August 17, 2006, indicating that request for reconsideration has been considered but 
does not place the application in condition for allowance. A Notice of Appeal was timely 
filed on September 8, 2006. This Appeal Brief is being timely filed. 



The real party in interest in this application is Broadcom Corporation of Irvine, 
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There are no known related appeals and/or interferences which will directly effect 
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or be directly effected by or have a bearing on the Board's decision in this appeal. 

IV. STATUS OF CLAIMS 
Claims 1, 2 and 4-38, all of the claims pending in the present application, are the 
subject of this appeal. Claims 1, 2, 4-12, 14, and 16-38 were rejected under 35 U.S.C. 
§1 02(b) as being anticipated by Beuk (U.S. Patent No. 5,774,673). Claims 13 and 15 
were rejected under 35 U.S.C. 103(a) as being unpatentable over Beuk in view of Meyer 
(U.S. Patent No. 6,611,495). 

V. STATUS OF AMENDMENTS 
Claims 1 and 2 were last amended in a Response filed on January 10, 2006. 
Claim 3 was cancelled. Claims 14 and 28 were last amended in a Response filed July 1 , 
2005. No further amendments have been made. Therefore, claims 1, 2, and 4-38 are 
currently pending. 

VI. SUMMARY OF CLAIMED SUBJECT MATTER 
The independent claims involved in this appeal are claims 1 , 14, and 28. 
Claim 1, upon which claims 2-13 and 33-34 are dependent, recites a method for 
controlling data flow across a link. The method includes the steps of transmitting a 
packet request message from a first station to a second station, determining if the packet 
request message is valid, transmitting a request acknowledge message from the second 
station to the first station, and determining if the request acknowledge message is valid 
(Specification, page 1, lines 16-23). The step of transmitting a packet request message 



further includes the step of generating the packet request message, which includes 
generating a request non-payload bit string corresponding to a pre-programmed packet 
request register. The packet request message and the request acknowledge message 
each include a control bit string, an identification bit string, and at least one parity bit. The 
control bit string identifies whether a frame is a control frame or a data frame. The 
identification bit string correlates the packet request message with a corresponding 
request acknowledge message (Specification, page 108, lines 19-28, Figures 28 and 29). 

Claim 14, upon which claims 15-27 and 35-36 are dependent, recites a data flow 
control method for controlling data transmitted across a high speed link. The method 
includes the step of transmitting a packet request message from a first station to a 
second station, said packet request message having a first identification number, a first 
control code group, and a first parity parameter associated therewith. The method further 
includes the step of storing the first identification number associated with the packet 
request message. The method also includes the step of transmitting a request 
acknowledge message from said second station to said first station, said request 
acknowledge message having a second identification number, a second control group, 
and a second parity parameter associated therewith. The method further includes the 
steps of determining if the first and second control groups are valid, determining if the 
second identification number matches the first identification number, and determining if 
the first and second parity parameters are valid (Specification, page 1, line 17 - page 2, 
line 7). The first control group and the second control group are configured to identify 
whether a frame is a control frame or a data frame. The first identification number and 
second identification number are configured to correlate the packet request message 
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with a corresponding request acknowledge message (Specification, page 106, line 1 - 
page 108, line 28, and Figures 28 and 29). 

Claim 28, upon which claims 29-32 and 37-38 are dependent, recites an 
apparatus for controlling data flow across a link. The apparatus includes a first 
transmitting unit for transmitting a packet request message from a first station to a second 
station, said packet request message including a first identification number, a first control 
code group, and a first parity parameter associated therewith. The apparatus also 
includes a storage unit for storing the first identification number associated with the 
packet request message, and a second transmitting unit for transmitting a request 
acknowledge message from said second station to said first station, said request 
acknowledge message having second identification number, a second control group, and 
a second parity parameter associated therewith. The apparatus further includes at least 
one flow logic unit for determining if the first and second control groups are valid, 
determining if the second identification number matches the first identification number, 
and determining if the first and second parity parameters are valid (Specification, page 2, 
lines 8-21). The first control group and the second control group are configured to identify 
whether a frame is a control frame or a data frame. The first identification number and 
second identification number are configured to correlate the packet request message 
with a corresponding request acknowledge message (Specification, page 106, line 1 - 
page 108, line 28, and Figures 28 and 29). 
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VII. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 
The grounds of rejection to be reviewed on appeal are the rejection of claims 1 , 2, 
4-12, 14, and 16-38 under 35 U.S.C. §102(b) as being anticipated by Beuk (U.S. Patent 
No. 5,774,673), and claims 1 3 and 1 5 under 35 U.S.C. 1 03(a) as being unpatentable over 
Beuk in view of Meyer (U.S. Patent No. 6,61 1,495). 

VIII. APPELLANT'S ARGUMENTS 

Appellants respectfully submit that each of pending claims 1, 2, and 4-38 recites 
subject matter that is not taught, disclosed, or suggested by the cited art. Each of the 
claims is being argued separately, and thus, each of the claims stands or falls alone. 

A. Claims 1. 2. 4-12. 14. and 16-38 are novel in view of Beuk 

In the final Office Action, claims 1, 2, 4-12, 14, and 16-38 were rejected under 35 
U.S.C. §1 02(b) as being anticipated by Beuk (U.S. Patent No. 5,774,673). The Final 
Office Action took the position that Beuk teaches each and every element recited in the 
rejected claims. Appellants submit that each of claims 1, 2, 4-12, 14, and 16-38 recite 
subject matter that is not taught or disclosed by Beuk, and as such, the Board's reversal 
of the rejection is respectfully requested. 

1) Claim 1 

Claim 1, upon which claims 2-13 and 33-34 are dependent, recites a method for 
controlling data flow across a link. The method includes the steps of transmitting a 
packet request message from a first station to a second station, determining if the packet 
request message is valid, transmitting a request acknowledge message from the second 
station to the first station, and determining if the request acknowledge message is valid. 
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The step of transmitting a packet request message further includes the step of 
generating the packet request message, which includes generating a request 
non-payload bit string corresponding to a pre-programmed packet request register. The 
packet request message and the request acknowledge message each include a control 
bit string, an identification bit string, and at least one parity bit. The control bit string 
identifies whether a frame is a control frame or a data frame. The identification bit string 
correlates the packet request message with a corresponding request acknowledge 
message. 

Appellants respectfully submit that claim 1 recites subject matter which is neither 
disclosed nor suggested by Beuk. 

Beuk discloses a system for communicating between a dynamic group of 
apparatuses. The system allows an apparatus to establish communication between a 
local application and applications in other-apparatuses. An active activation unit invites 
applications in other apparatuses to join by using a message sending unit to transmit a 
broadcast frame to all apparatuses which requests activation of the selected application. 
The broadcast frame specifies which application is being activated. The active activation 
unit then determines a communication channel which corresponds to the application and 
the selected application, which is stored in storage, is executed by an execution unit. The 
broadcast frame is received by a message receiving unit in other apparatuses. A passive 
activation unit verifies whether the receiving apparatus has an application, which 
corresponds to the specified application and whether such an application needs to be 
activated (Col. 1, line 57 - Col. 3, line 25). 

Appellants note that a "claim is anticipated only if each and every element as set 
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forth in the claim is found, either expressly or inherently described, in a single prior art 
reference" Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d 628, 2 USPQ2d 1051, 
1053 (Fed. Cir. 1987). Additionally, the "identical invention must be shown in as complete 
detail as is contained in the... claim" Richardson v. Suzuki Motor Co., 868 F.2d 1226, 
1236, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

Appellants submit that the final Office Action has failed to establish a prima facie 
case for anticipation as Beuk fails to disclose each and every element of claim 1. 
Specifically, Beuk does not disclose or suggest "wherein said step of transmitting a 
packet request message further comprises the step of generating the packet request 
message, the step of generating the packet request message comprising generating a 
request non-payload bit string corresponding to a pre-programmed packet request 
register," as recited in claim 1 . Beuk also fails to disclose or suggest "wherein the packet 
request message and the request acknowledge message each include a control bit 
string, an identification bit string, and at least one parity bit," as recited in claim 1. 

In the response to arguments section, the Office Action appears to take the 
position that the TYPE field of Beuk corresponds to "a request non-payload bit string 
corresponding to a pre-programmed packet request register," as recited in claim 1. The 
Office Action also takes the position that the TYPE field of Beuk corresponds to the 
control bit string, identification bit string and at least one parity bit that are included in the 
packet request message and the request acknowledge message of the present 
invention. Appellants respectfully submit, however, that Beuk contains no disclosure 
regarding the TYPE field being a request non-payload bit string corresponding to a 
pre-programmed packet request register, and a control bit string, identification bit string 
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and at least one parity bit. 

Rather, Beuk merely discloses that various frames (acknowledgement frame, 
broadcast frame, group frame) include a TYPE field. Specifically, Beuk teaches that the 
"TYPE field comprises an A/M field and an B/G field. The A/M field is used to distinguish 
between an acknowledgment frame and a message frame. The B/G field is used to 
distinguish between the two types of message frames: a broadcast frame and a group 
frame" (Beuk, Column 1 2, lines 36-42). Beuk does not disclose or suggest that the TYPE 
field corresponds to any type of register. Beuk only discloses that the TYPE field includes 
entries which indicate whether it is an acknowledgement or message. Appellants 
respectfully submit that this disclosure does not correspond to the generating of a request 
non-payload bit string corresponding to a pre-programmed packet request register, as 
recited in the claims. 

Furthermore, the message receiving means of Beuk does not correspond to the 
pre-programmed packet request register of the present invention. Beuk discloses that 
the message receiving means 210 if for receiving a message frame (Beuk, Column 11, 
lines 33-34). Further, Beuk discloses that "the message receiving means 210 only 
receives a group frame 630 if the channel field specifies a channel which has been locally 
activated (i.e. in the receiving apparatus) by the channel activation means 240" (Beuk, 
Column 12, lines 9-12). Beuk also discloses that the message receiving means 210 
receives the "activation request message 500 and verifies that the message has been 
received correctly." Beuk, however, fails to disclose or suggest that the message 
receiving means is pre-programmed and that it corresponds to the request non-payload 
bit string. 
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Beuk, as mentioned above, merely discloses that the message receiving means 
210 is a component which may receive a group frame under certain circumstances. Beuk 
does not disclose or suggest that generating a packet request message includes 
generating a request non-payload bit string corresponding to a pre-programmed packet 
request register, as recited in the claims. In other words, according to the Office Action's 
rationale, Beuk allegedly discloses that the TYPE field of the frames 610 and 630 is 
generated in order to correspond to the message receiving means 210. However, Beuk 
contains no such disclosure. Beuk only discloses that the message receiving means 210, 
as suggested by its name, may receive message frames such as the group frame 630. 
Therefore, for at least the reasons discussed above, Beuk fails to disclose or suggest 
"wherein said step of transmitting a packet request message further comprises the step 
of generating the packet request message, the step of generating the packet request 
message comprising generating a request non-payload bit string corresponding to a 
pre-programmed packet request register," as recited in claim 1. 

For at least the reasons discussed above, Appellants submit that Beuk fails to 
disclose or suggest all of the elements of claim 1 . Accordingly, the Board's consideration 
and reversal of the rejection thereof is respectfully requested. 

2) Claim 2 

Claim 2 is dependent upon claim 1 , and recites further limitations. Thus, claim 2 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 
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3) Claim 3 

Claim 3 has been cancelled without prejudice or disclaimer. 

4) Claim 4 

Claim 4 is dependent upon claim 1 , and recites further limitations. Thus, claim 4 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

5) Claim 5 

Claim 5 is dependent upon claim 1 , and recites further limitations. Thus, claim 5 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

5) Claim 5 

Claim 5 is dependent upon claim 1 , and recites further limitations. Thus, claim 5 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

6) Claim 6 

Claim 6 is dependent upon claim 1, and recites further limitations. Thus, claim 6 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

7) Claim 7 
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Claim 7 is dependent upon claim 1 , and recites further limitations. Thus, claim 7 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

8) Claim 8 

Claim 8 is dependent upon claim 1 , and recites further limitations. Thus, claim 8 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

9) Claim 9 

Claim 9 is dependent upon claim 1 , and recites further limitations. Thus, claim 9 is 
patentable at least for the reasons claim 1 is patentable, and further, because it recites 
additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

10) Claim 10 

Claim 10 is dependent upon claim 1, and recites further limitations. Thus, claim 

10 is patentable at least for the reasons claim 1 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

11) Claim 11 

Claim 1 1 is dependent upon claim 1 , and recites further limitations. Thus, claim 

1 1 is patentable at least for the reasons claim 1 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
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reversed and this claim allowed. 

12) Claim 12 

Claim 12 is dependent upon claim 1, and recites further limitations. Thus, claim 
12 is patentable at least for the reasons claim 1 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

13) Claim 14 

Claim 14, upon which claims 15-27 and 35-36 are dependent, recites a data flow 
control method for controlling data transmitted across a high speed link. The method 
includes the step of transmitting a packet request message from a first station to a 
second station, said packet request message having a first identification number, a first 
control code group, and a first parity parameter associated therewith. The method further 
includes the step of storing the first identification number associated with the packet 
request message. The method also includes the step of transmitting a request 
acknowledge message from said second station to said first station, said request 
acknowledge message having a second identification number, a second control group, 
and a second parity parameter associated therewith. The method further includes the 
steps of determining if the first and second control groups are valid, determining if the 
second identification number matches the first identification number, and determining if 
the first and second parity parameters are valid. The first control group and the second 
control group are configured to identify whether a frame is a control frame or a data 
frame. The first identification number and second identification number are configured to 
correlate the packet request message with a corresponding request acknowledge 
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message. 

Appellants respectfully submit that claim 14 recites subject matter which is neither 
disclosed nor suggested by Beuk. 

As outlined above, Beuk discloses a system for communicating between a 
dynamic group of apparatuses. The system allows an apparatus to establish 
communication between a local application and applications in other apparatuses. An 
active activation unit invites applications in other apparatuses to join by using a message 
sending unit to transmit a broadcast frame to all apparatuses which requests activation 
of the selected application. The broadcast frame specifies which application is being 
activated. The active activation unit then determines a communication channel which 
corresponds to the application and the selected application, which is stored in storage, is 
executed by an execution unit. The broadcast frame is received by a message receiving 
unit in other apparatuses. A passive activation unit verifies whether the receiving 
apparatus has an application, which corresponds to the specified application and 
whether such an application needs to be activated (Col. 1, line 57 - Col. 3, line 25). 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference" Verdegaal 
Bros. v. Union Oil Co. of California, 814 F.2d 628, 2 USPQ2d 1051, 1053 (Fed. Cir. 
1987). Appellants submit, as will be explained below, that Beuk fails to disclose or 
suggest each and every element of claim 14. 

More specifically, Beuk fails to disclose or suggest that the first identification 
number and the second identification number are configured to correlate the packet 
request message with a corresponding request acknowledge message, as recited in 
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claim 14. In one embodiment of the present invention, the packet request message and 
the request acknowledge message both include an identification string. 

According to an aspect of the invention, this identification string is used to identify 
and correlate a specific packet request message with the corresponding request 
acknowledge message. Through implementation of this correlation scheme, accurate 
flow control across a high speed link is generated and, therefore, queue or buffer 
management requirements are reduced at the receiving end (Specification, page 108, 
lines 19-28). Appellants respectfully assert that Beuk fails to disclose or suggest that the 
identification strings are configured to correlate the packet request message with the 
corresponding request acknowledge message, as recited in the present claims. 

The final Office Action took the position that the identification bit string correlating 
the packet request message with a corresponding request acknowledge message "is 
anticipated by the channel field (first identification number) shown in group frame 630 
(packet request message) of figure 3 that is copied (correlates) to the channel field 
(second identification number) of acknowledgement frame 640 (request 
acknowledgment message) of figure 3 and that is used to filter acknowledgement 
messages as spoken of on column 4, lines 38-48 and column 12, lines 19-28" (Office 
Action, page 8, lines 15-22). Appellants respectfully disagree with the final Office 
Action's rationale. Appellants respectfully assert that copying a first identification number 
to another location does not produce a second identification number. Further, if the 
channel field is merely copied to a different location as disclosed in Beuk there would be 
no need to determine "if the second identification number matches the first identification 
number," as recited in claim 14. Appellants further assert that copying a field to another 
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field is not the same as correlating a request message with an acknowledge message, as 
recited in the present claims. 

Additionally, Beuk specifically discloses that the channel field, included in the 
group frame 630, is used for identifying a communication channel. Each apparatus of 
Beuk includes channel activation means 240 for locally activating specific communication 
channels. The message sending means 200 only transmits a group frame 630 if the 
channel field specifies a channel which has been locally activated by the channel 
activation means 240 (Beuk, Column 11, line 67 - Column 12, line 7). Beuk further 
discloses that "the acknowledgement frame 640 for acknowledging a group frame 630 
may comprise the same channel field as used for the group frame 630. In that case, the 
acknowledge sending means 220 will only transmit an acknowledgement frame, 
acknowledging the reception of the group frame, if the message receiving means 210 of 
Fig. 2 correctly receives a group frame, whose channel field specifies a locally activated 
channel. The acknowledge sending means 220 copies the channel identification from 
the channel field of the received group frame to the channel field of the acknowledgement 
frame" (Beuk, Column 12, lines 10-28). 

Therefore, according to Beuk, the channel field is utilized to identify a 
communication channel. In addition, according to Beuk, a determination is made 
whether to transmit a group frame based on whether the channel field specifies a locally 
activated channel. However, Beuk does not disclose or suggest that the channel field is 
used to identify and correlate a specific request message with a corresponding 
acknowledgment message. Beuk merely discloses that the acknowledgment frame may 
include the same channel field as the group frame, and that the channel identification 
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may be copied from the channel field of the received group frame to the channel field of 
the acknowledgment frame. The channel identification, as suggested by its name, is 
used to identify the communication channel used. Beuk does not disclose or suggest that 
the channel field or channel identification is used to correlate a specific request message 
with a corresponding acknowledgment message, as recited in the present claims. 

The final Office Action acknowledges that the channel field of Beuk is used to 
identify a communication channel, but alleges that the channel field also "correlates a 
packet request message with a corresponding request acknowledge message" (Office 
Action, page 16, line 19 - page 17, line 2). The final Office Action offers no rationale for 
this conclusion besides stating that the channel field is copied from the group frame 640 
to the acknowledgment frame 640. However, as outlined above, the mere fact that Beuk 
discloses that the channel field may be copied from one location to another does not 
anticipate the limitation of "wherein the first identification number and the second 
identification number are configured to correlate the packet request message with a 
corresponding request acknowledge message," as recited in claim 14. 

Thus, for at least the reasons discussed above, Appellants respectfully submit that 
Beuk fails to disclose or suggest all of the elements of claim 14. Accordingly, the Board's 
consideration and reversal of the rejection thereof is respectfully requested. 

14) Claim 16 

Claim 16 is dependent upon claim 14, and recites further limitations. Thus, claim 
16 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 
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15) Claim 17 

Claim 17 is dependent upon claim 14, and recites further limitations. Thus, claim 

17 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

16) Claim 18 

Claim 18 is dependent upon claim 14, and recites further limitations. Thus, claim 

18 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

17) Claim 19 

Claim 19 is dependent upon claim 14, and recites further limitations. Thus, claim 

19 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

18) Claim 20 

Claim 20 is dependent upon claim 14, and recites further limitations. Thus, claim 

20 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

19) Claim 21 

Claim 21 is dependent upon claim 14, and recites further limitations. Thus, claim 

21 is patentable at least for the reasons claim 14 is patentable, and further, because it 
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recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

20) Claim 22 

Claim 22 is dependent upon claim 14, and recites further limitations. Thus, claim 

22 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

21) Claim 23 

Claim 23 is dependent upon claim 14, and recites further limitations. Thus, claim 

23 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

22) Claim 24 

Claim 24 is dependent upon claim 14, and recites further limitations. Thus, claim 

24 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

23) Claim 25 

Claim 25 is dependent upon claim 14, and recites further limitations. Thus, claim 

25 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

24) Claim 26 
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Claim 26 is dependent upon claim 14, and recites further limitations. Thus, claim 

26 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

25) Claim 27 

Claim 27 is dependent upon claim 14, and recites further limitations. Thus, claim 

27 is patentable at least for the reasons claim 14 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

26) Claim 28 

Claim 28, upon which claims 29-32 and 37-38 are dependent, recites an 
apparatus for controlling data flow across a link. The apparatus includes a first 
transmitting unit for transmitting a packet request message from a first station to a second 
station, said packet request message including a first identification number, a first control 
code group, and a first parity parameter associated therewith. The apparatus also 
includes a storage unit for storing the first identification number associated with the 
packet request message, and a second transmitting unit for transmitting a request 
acknowledge message from said second station to said first station, said request 
acknowledge message having second identification number, a second control group, and 
a second parity parameter associated therewith. The apparatus further includes at least 
one flow logic unit for determining if the first and second control groups are valid, 
determining if the second identification number matches the first identification number, 
and determining if the first and second parity parameters are valid. The first control group 
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and the second control group are configured to identify whether a frame is a control frame 
or a data frame. The first identification number and second identification number are 
configured to correlate the packet request message with a corresponding request 
acknowledge message. 

Appellants respectfully submit that claim 28 recites subject matter which is neither 
disclosed nor suggested by Beuk. 

As discussed above, Beuk discloses a system for communicating between a 
dynamic group of apparatuses. The system allows an apparatus to establish 
communication between a local application and applications in other apparatuses. An 
active activation unit invites applications in other apparatuses to join by using a message 
sending unit to transmit a broadcast frame to all apparatuses which requests activation 
of the selected application. The broadcast frame specifies which application is being 
activated. The active activation unit then determines a communication channel which 
corresponds to the application and the selected application, which is stored in storage, is 
executed by an execution unit. The broadcast frame is received by a message receiving 
unit in other apparatuses. A passive activation unit verifies whether the receiving 
apparatus has an application, which corresponds to the specified application and 
whether such an application needs to be activated (Col. 1, line 57 - Col. 3, line 25). 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference" Verdegaal 
Bros. v. Union Oil Co. of California, 814 F.2d 628, 2 USPQ2d 1051, 1053 (Fed. Cir. 
1987). Appellants submit, as will be discussed below, that Beuk fails to disclose or 
suggest each and every element of claim 28. 
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In particular, as discussed above with respect to claim 14, Beuk fails to disclose 
or suggest that the first identification number and the second identification number are 
configured to correlate the packet request message with a corresponding request 
acknowledge message, as recited in claim 28. In one embodiment of the present 
invention, the packet request message and the request acknowledge message both 
include an identification string. 

As mentioned above, according to an aspect of the invention, this identification 
string is used to identify and correlate a specific packet request message with the 
corresponding request acknowledge message. Through implementation of this 
correlation scheme, accurate flow control across a high speed link is generated and, 
therefore, queue or buffer management requirements are reduced at the receiving end 
(Specification, page 108, lines 19-28). Appellants respectfully assert that Beuk fails to 
disclose or suggest that the identification strings are configured to correlate the packet 
request message with the corresponding request acknowledge message, as recited in 
the present claims. 

The final Office Action took the position that the identification bit string correlating 
the packet request message with a corresponding request acknowledge message "is 
anticipated by the channel field (first identification number) shown in group frame 630 
(packet request message) of figure 3 that is copied (correlates) to the channel field 
(second identification number) of acknowledgement frame 640 (request 
acknowledgment message) of figure 3 and that is used to filter acknowledgement 
messages as spoken of on column 4, lines 38-48 and column 12, lines 19-28" (Office 
Action, page 8, lines 15-22). Appellants respectfully disagree with the final Office 
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Action's rationale. Appellants respectfully assert that copying a first identification number 
to another location does not produce a second identification number. Further, if the 
channel field is merely copied to a different location as disclosed in Beuk there would be 
no need to determine "if the second identification number matches the first identification 
number," as recited in claim 28. Appellants further assert that copying a field to another 
field is not the same as correlating a request message with an acknowledge message, as 
recited in the present claims. 

Additionally, Beuk specifically discloses that the channel field, included in the 
group frame 630, is used for identifying a communication channel. Each apparatus of 
Beuk includes channel activation means 240 for locally activating specific communication 
channels. The message sending means 200 only transmits a group frame 630 if the 
channel field specifies a channel which has been locally activated by the channel 
activation means 240 (Beuk, Column 11, line 67 - Column 12, line 7). Beuk further 
discloses that "the acknowledgement frame 640 for acknowledging a group frame 630 
may comprise the same channel field as used for the group frame 630. In that case, the 
acknowledge sending means 220 will only transmit an acknowledgement frame, 
acknowledging the reception of the group frame, if the message receiving means 210 of 
Fig. 2 correctly receives a group frame, whose channel field specifies a locally activated 
channel. The acknowledge sending means 220 copies the channel identification from 
the channel field of the received group frame to the channel field of the acknowledgement 
frame" (Beuk, Column 12, lines 10-28). 

Therefore, according to Beuk, the channel field is utilized to identify a 
communication channel. In addition, according to Beuk, a determination is made 
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whether to transmit a group frame based on whether the channel field specifies a locally 
activated channel. However, Beuk does not disclose or suggest that the channel field is 
used to identify and correlate a specific request message with a corresponding 
acknowledgment message. Beuk merely discloses that the acknowledgment frame may 
include the same channel field as the group frame, and that the channel identification 
may be copied from the channel field of the received group frame to the channel field of 
the acknowledgment frame. The channel identification, as suggested by its name, is 
used to identify the communication channel used. Beuk does not disclose or suggest that 
the channel field or channel identification is used to correlate a specific request message 
with a corresponding acknowledgment message, as recited in the present claims. 

The final Office Action acknowledges that the channel field of Beuk is used to 
identify a communication channel, but alleges that the channel field also "correlates a 
packet request message with a corresponding request acknowledge message" (Office 
Action, page 16, line 19 - page 17, line 2). The final Office Action offers no rationale for 
this conclusion besides stating that the channel field is copied from the group frame 640 
to the acknowledgment frame 640. However, as outlined above, the mere fact that Beuk 
discloses that the channel field may be copied from one location to another does not 
anticipate the limitation of "wherein the first identification number and the second 
identification number are configured to correlate the packet request message with a 
corresponding request acknowledge message," as recited in claim 28. 

Thus, for at least the reasons discussed above, Appellants respectfully submit that 
Beuk fails to disclose or suggest all of the elements of claim 28. Accordingly, the Board's 
consideration and reversal of the rejection thereof is respectfully requested. 
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27) Claim 29 

Claim 29 is dependent upon claim 28, and recites further limitations. Thus, claim 

29 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

28) Claim 30 

Claim 30 is dependent upon claim 28, and recites further limitations. Thus, claim 

30 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

29) Claim 31 

Claim 31 is dependent upon claim 28, and recites further limitations. Thus, claim 

31 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

30) Claim 32 

Claim 32 is dependent upon claim 28, and recites further limitations. Thus, claim 

32 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

31) Claim 33 

Claim 33 is dependent upon claim 28, and recites further limitations. Thus, claim 

33 is patentable at least for the reasons claim 28 is patentable, and further, because it 
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recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

32) Claim 34 

Claim 34 is dependent upon claim 28, and recites further limitations. Thus, claim 

34 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

33) Claim 35 

Claim 35 is dependent upon claim 28, and recites further limitations. Thus, claim 

35 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

34) Claim 36 

Claim 36 is dependent upon claim 28, and recites further limitations. Thus, claim 

36 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

35) Claim 37 

Claim 37 is dependent upon claim 28, and recites further limitations. Thus, claim 

37 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

36) Claim 38 
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Claim 38 is dependent upon claim 28, and recites further limitations. Thus, claim 
38 is patentable at least for the reasons claim 28 is patentable, and further, because it 
recites additional limitations. Accordingly, it is respectfully requested that this rejection be 
reversed and this claim allowed. 

B. Claims 13 and 15 are non-obvious over Beuk in view of Meyer 

Claims 13 and 15 were rejected under 35 U.S.C. §103(a) as being unpatentable 
over Beuk in view of Meyer (U.S. Patent No. 6,61 1 ,495). The final Office Action took the 
position that Beuk teaches all of the elements of claims 13 and 15, with the exception of 
the starting of a timer upon transmission of a packet request message and retransmitting 
the message if a predetermined period of time has passed. The final Office Action then 
relies upon Meyer to cure the deficiency in Beuk. 

Appellants submit that each of claims 13 and 15 recite subject matter that is not 
taught or disclosed by the combination of Beuk and Meyer, and as such, the Board's 
reversal of the rejection is respectfully requested. 

1) Claim 13 

Claim 13 is dependent upon claim 1, and additionally recites "starting a timer upon 
transmitting the packet request message; determining if a predetermined period of time 
has expired; and resending the packet request message if the timer is determined to 
have expired." 

Beuk is discussed above. Meyer discloses a system and method for improved 
data transfer in packet-switched communication networks. A sender receives an 
acknowledgement message indicating that the intended recipient received a data packet, 
and a retransmission timer is initialized with a value that compensates for the time lag 
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between the transmission of a data packet by the sender and the receipt of an 
acknowledgement message. 

Appellants respectfully submit that Meyer fails to cure the deficiencies in Beuk 
with respect to claim 1 . Meyer, like Beuk, does not disclose or suggest "wherein said step 
of transmitting a packet request message further comprises the step of generating the 
packet request message, the step of generating the packet request message comprising 
generating a request non-payload bit string corresponding to a pre-programmed packet 
request register," and "wherein the packet request message and the request 
acknowledge message each include a control bit string, an identification bit string, and at 
least one parity bit," as recited in claim 1 . Therefore, the combination of Beuk and Meyer 
fails to disclose or suggest all of the elements of claim 1 3. 

Thus, claim 13 is patentable at least for the reasons claim 1 is patentable, and 
further, because it recites additional limitations. Accordingly, it is respectfully requested 
that this rejection be reversed and this claim allowed. 

2) Claim 15 

Claim 15 is dependent upon claim 14, and additionally recites "starting a timer 
upon transmitting the packet request message; determining if a predetermined period of 
time has expired; and re-transmitting the packet request message if the predetermined 
period of time is determined to have expired." 

Appellants submit that Meyer, like Beuk, fails to disclose or suggest all of the 
elements of claim 14. Both Meyer and Beuk fail to disclose or suggest that the first 
identification number and the second identification number are configured to correlate 
the packet request message with a corresponding request acknowledge message, as 
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recited in claim 14. . Therefore, the combination of Beuk and Meyer fails to disclose or 
suggest all of the elements of claim 15. 

Thus, claim 15 is patentable at least for the reasons claim 14 is patentable, and 
further, because it recites additional limitations. Accordingly, it is respectfully requested 
that this rejection be reversed and this claim allowed. 

For all of the above noted reasons, it is strongly contended that certain clear 
differences exist between the present invention as claimed in claims 1 , 2, and 4-38 and 
the prior art relied upon by the Examiner. It is further contended that these differences 
are more than sufficient that the present invention would not have been obvious to a 
person having ordinary skill in the art at the time the invention was made. 

This final rejection being in error, therefore, it is respectfully requested that this 
honorable Board of Patent Appeals and Interferences reverse the Examiner's decision in 
this case and indicate the allowability of application claims 1, 2 and 4-38. 

In the event that this paper is not being timely filed, the applicant respectfully 
petitions for an appropriate extension of time. Any fees for such an extension together 
with any additional fees which may be due with respect to this paper may be charged to 
Counsel's Deposit Account 50-2222. 



Respectfully submitted, 



SQUIRE, SANDERS & DEMPSEY LLP 



MajiaS. AlBassam 
Attorney for Applicant(s) 
Registration No. 54,749 
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APPENDIX 1 
CLAIMS ON APPEAL 

1 . (Previously Presented) A method for controlling data flow across a link, said method 
comprising the steps of: 

transmitting a packet request message from a first station to a second station; 
determining if the packet request message is valid; 

transmitting a request acknowledge message from the second station to the first 
station; 

determining if the request acknowledge message is valid, 

wherein said step of transmitting a packet request message further comprises the 
step of generating the packet request message, the step of generating the packet request 
message comprising generating a request non-payload bit string corresponding to a 
pre-programmed packet request register, 

wherein the packet request message and the request acknowledge message each 
include a control bit string, an identification bit string, and at least one parity bit, and 

wherein said control bit string identifies whether a frame is a control frame or a 
data frame and said identification bit string correlates the packet request message with 
a corresponding request acknowledge message. 

2. (Previously Presented) A method for controlling data flow across a link as recited in 
claim 1 , wherein said generated packet request message includes a request control code 
group and a request data code group. 
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3. (Canceled). 

4. (Original) A method for controlling data flow across a link as recited in claim 2, 
wherein said step of generating the packet request message having a request data code 
group further comprises generating a request data code group bit string having at least 
one request parity bit and at least one request identification bit. 

5. (Original) A method for controlling data flow across a link as recited in claim 4, 
wherein said step of generating the packet request message having at least one request 
parity bit further comprises generating a first request parity bit corresponding to a parity 
of said request control code group bit string and a second request parity bit 
corresponding to a parity of said request data code group. 

6. (Original) A method for controlling data flow across a link as recited in claim 1 , 
wherein said step of transmitting a request acknowledge message further comprises the 
step of generating the request acknowledge message, wherein the request acknowledge 
message includes an acknowledge control code group and an acknowledge data code 
group. 

7. (Original) A method for controlling data flow across a link as recited in claim 6, 
wherein said step of transmitting a request acknowledge message having an 
acknowledge control code group further comprises generating an acknowledge 
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non-payload bit string corresponding to a pre-programmed packet acknowledge register. 

8. (Original) A method for controlling data flow across a link as recited in claim 6, 
wherein said step of transmitting a request acknowledge message having an 
acknowledge data code group further comprises generating an acknowledge data bit 
string having at least one acknowledge parity bit and at least one acknowledge 
identification bit. 

9. (Original) A method for controlling data flow across a link as recited in claim 8, 
wherein said at least one acknowledge parity bit further comprises a first acknowledge 
parity bit corresponding to a parity of said acknowledge control code group and a second 
acknowledge parity bit corresponding to a parity of said acknowledge data code group. 

10. (Original) A method for controlling data flow across a link as recited in claim 1, 
wherein said step of determining if the packet request message is valid further comprises 
determining if at least one request parity bit for the packet request message is valid and 
determining if a request control code group message is valid. 

11. (Original) A method for controlling data flow across a link as recited in claim 1, 
wherein said step of determining if the request acknowledge message is valid further 
comprises the steps of: 

comparing an acknowledge identification parameter associated with the request 
acknowledge message to a stored list of valid acknowledge identification parameters; 
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determining if an acknowledge control code group associated with the request 
acknowledge message is valid; and 

determining if at least one acknowledge parity parameter is satisfied. 

12. (Original) A method for controlling data flow across a link as recited in claim 11, 
wherein said step of determining if at least one acknowledge parity parameter is satisfied 
further comprises determining if a first acknowledge parity bit associated with the 
acknowledge identification parameter is satisfied and determining if a second 
acknowledge parity bit associated with the acknowledge control code group is satisfied. 

13. (Original) A method for controlling data flow across a link as recited in claim 1, said 
method further comprising the steps of: 

starting a timer upon transmitting the packet request message; 
determining if a predetermined period of time has expired; and 
resending the packet request message if the timer is determined to have expired. 

14. (Previously Presented) A data flow control method for controlling data transmitted 
across a high speed link, said method comprising the steps of: 

transmitting a packet request message from a first station to a second station, said 
packet request message having a first identification number, a first control code group, 
and a first parity parameter associated therewith; 

storing the first identification number associated with the packet request message; 

transmitting a request acknowledge message from said second station to said first 
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station, said request acknowledge message having a second identification number, a 
second control group, and a second parity parameter associated therewith; 

determining if the first and second control groups are valid; 

determining if the second identification number matches the first identification 
number; 

determining if the first and second parity parameters are valid; 

wherein the first control group and the second control group are configured to 
identify whether a frame is a control frame or a data frame, and wherein the first 
identification number and the second identification number are configured to correlate 
the packet request message with a corresponding request acknowledge message. 

15. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 14, said method further comprising the steps of: 

starting a timer upon transmitting the packet request message; 
determining if a predetermined period of time has expired; and 
re-transmitting the packet request message if the predetermined period of time is 
determined to have expired. 

16. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 14, wherein said step of transmitting a packet request 
message step further comprises the step of generating the packet request message, 
wherein said generated packet request message includes a first control group bit string, 
a first identification number bit string, a first parity bit corresponding to the first control 
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group bit string, and a second parity bit corresponding to the identification number bit 
string. 

17. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 14, wherein said transmitting a request acknowledge 
message step further comprises generating the request acknowledge message, wherein 
said generated request acknowledge message includes a second control group bit string, 
a second identification number bit string, a third parity bit corresponding to the second 
control group bit string, and a fourth parity bit corresponding to the second identification 
number bit string. 

18. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 14, wherein said step of determining if the second 
identification number matches the first identification number further comprises the steps 
of: 

comparing the first identification number to the second identification number; and 
determining if the first identification number is identical to the second identification 
number. 

19. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 14, wherein said step of determining if said first and second 
control groups are valid further comprises the steps of: 

receiving the first and second control groups in a flow logic control module; and 
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determining if the first and second control groups are of a valid and recognized 
format. 

20. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 14, wherein said transmitting a packet request message 
further comprises transmitting the packet request message, wherein the first parity 
parameter further comprises a request identification parity bit and a request control code 
group parity bit. 

21. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 20, wherein said step of determining if a first parity 
parameter is valid further comprises the steps of determining if the request identification 
parity bit is valid and determining if the request control code group parity bit is valid. 

22. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 21, wherein said step of determining if the request 
identification parity bit is valid further comprises the step of determining if the request 
identification parity bit represents the parity of the first identification number. 

23. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 21, wherein said step of determining if the request control 
code group parity bit is valid further comprises the step of determining if the request 
control code group parity bit represents the parity of the first control code group. 
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24. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 14, wherein said transmitting a request acknowledge 
message further comprises transmitting the request acknowledge message, wherein the 
second parity parameter further comprises an acknowledge identification parity bit and 
an acknowledge control code group parity bit. 

25. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 24, wherein said step of determining if a second parity 
parameter is valid further comprises the steps of determining if the acknowledge 
identification parity bit is valid and determining if the acknowledge control code group 
parity bit is valid. 

26. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 25, wherein said step of determining if the acknowledge 
identification parity bit is valid further comprises the step of determining if the 
acknowledge identification parity bit represents the parity of the second identification 
number. 

27. (Original) A data flow control method for controlling data transmitted across a high 
speed link as recited in claim 25, wherein said step of determining if the acknowledge 
control code group parity bit is valid further comprises the step of determining if the 
acknowledge control code group parity bit represents the parity of the second control 
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code group. 



28. (Previously Presented) An apparatus for controlling data flow across a link, said 
apparatus comprising: 

a first transmitting unit for transmitting a packet request message from a first 
station to a second station, said packet request message including a first identification 
number, a first control code group, and a first parity parameter associated therewith; 

storage unit for storing the first identification number associated with the packet 
request message; 

a second transmitting unit for transmitting a request acknowledge message from 
said second station to said first station, said request acknowledge message having a 
second identification number, a second control group, and a second parity parameter 
associated therewith; and 

at least one flow logic unit for determining if the first and second control groups are 
valid, determining if the second identification number matches the first identification 
number, and determining if the first and second parity parameters are valid; 

wherein the first control group and the second control group are configured to 
identify whether a frame is a control frame or a data frame, and wherein the first 
identification number and the second identification number are configured to correlate 
the packet request message with a corresponding request acknowledge message. 

29. (Original) An apparatus for controlling data flow in across a link as recited in claim 28, 
wherein said first transmitting unit further comprises a first high speed interface of a first 
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network switch. 

30. (Original) An apparatus for controlling data flow in across a link as recited in claim 28, 
wherein said second transmitting unit further comprises a second high speed interface of 
a second network switch. 

31 . (Original) An apparatus for controlling data flow in across a link as recited in claim 28, 
wherein said storage unit further comprises a memory within said first transmitting unit. 

32. (Original) An apparatus for controlling data flow in across a link as recited in claim 28, 
wherein said at least one flow logic unit further comprises: 

a first flow control logic module, said first flow control logic module being 
positioned within a first network switch; and 

a second flow control logic module, said second flow control logic module being 
positioned within a second network switch. 

33. (Original) A method as recited in claim 1, wherein said step of transmitting a packet 
request message comprises transmitting a packet request ordered set. 

34. (Original) A method as recited in claim 1, wherein said step of transmitting a request 
acknowledge message comprises transmitting a request acknowledge ordered set. 

35. (Original) A method as recited in claim 14, wherein said step of transmitting a packet 
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request message comprises transmitting a packet request ordered set. 

36. (Original) A method as recited in claim 14, wherein said step of transmitting a request 
acknowledge message comprises transmitting a request acknowledge ordered set. 

37. (Original) An apparatus as recited in claim 28, wherein said packet request message 
comprises a packet request ordered set. 

38. (Original) An apparatus as recited in claim 28, wherein said request acknowledge 
message comprises a request acknowledge ordered set. 
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APPENDIX 2 
EVIDENCE APPENDIX 

No evidence under section 37 C.F.R. 1.130, 1.131, or 1.132 has been entered or 
will be relied upon by Appellants in this appeal. 
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APPENDIX 3 
RELATED PROCEEDINGS APPENDIX 

No decisions of the Board or of any court have been identified under 37 C.F.R. 
§41 .37(c)(1)(h). 
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APPENDIX 4 

DRAWINGS OF APPLICATION SERIAL NO. 09/709,532 
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